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METHOD FOR REQUEST AND RESPONSE DIRECT DATA TRANSFER AND 
MANAGEMENT OF CONTENT MANIFESTS 



BACKGROUND OF THE INVENTION 




\ / This application claims the benefit of U.S. Provisional Application No. 60/ filed May 

25, 2000, the entire disclosure of which hereby incorporated by reference. 

1. Technical Field 

The present invention relates to the field of the automated exchange of computerized data. 
More particularly, the invention prc^ 

exchange of information between ap plication prog rams running on di fferent opg rating syste ms. 
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2. Related Information 



Businesses and individuals have become increasing reliant upon the automated exchange 
of data between computers, computer programs and software applications. Businesses and 
15 individuals automatically interact between their own internal line of business, productivity and 
knowledge management applications, the applications used by their customers and partners, and 
services provided by their commercial and corporate providers. The use of a variety of different 
operating systems and software applications by those wishing to automatically exchange data has 
made the exchange process difficult and expensive. 

Conventionally, programmers at twc^usinesses wishing to automatically exchange data 
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would have to agree on how the information would be exchanged. For example, when company 
A decides to order 10 parts having a pkrt number 3614 for delivery on April 28, 2001 , company 
A would send company B a data stream JBimilar to 10,36 14, April 28,2001 . The programmers at 
each company would have to modify application programs at the two locations to include 

computer code for the formation, transport and protocol used for the exchange of such 

^ - \ 

information. Furthermore, eachfiledwould haw to be a predetermined length and transmitted in 
the correct order. 

What is needed is an approach that allows for the efficient automated exchange of data 
between application programs operating on different operating system platforms. 

SUMMARY OF THE INVENTION 

The present invention provides a framework that allows for the efficient exchange of data 
between application programs even when the application programs are operating on different 
operating system platforms. 

The present invention provides a method for exchanging data between a source location 
and a destination location. The method includes the initial step of generating a data file with a 
mar kup lan guage in accordance with a predetermined schema. A software envelope containing 
the data file is then generated and transmitted to the destination location. At the destination 
location, an object is created from the data file with a plugin object corresponding to the 
predetermined schema. 
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4- — y A second envelope maybe automatically be generated from the information contained in 
// the first software envelope. The^econd envelope may have a destination address matching the 
source address of the first envelope. iMternatively, the second envelope may have a destination 
address determined by state information contained in the first envelope. 

The software envelope may be transmitted via electronic mail, HTTP or an intermediate 

server. 

The advantages of the present invention may also be provided by a computer-readable 

medium having stored thereon a particular data structure. The data structure includes: (a) a first 

field containing address information; (b) a second data field containing the identification of a 

predetermined schema; and (c) a third data field containing a data file formatted in a markup 

language in accordance with the schema. 

Other features and advantages of the invention will become apparent with reference to the 
following detailed description and the figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation in the 
accompanying figures in which like reference numerals indicate similar elements and in which: 
Figure 1 is a schematic diagram of a conventional general-purpose digital computing 
environment that can be used to implement various aspects of the invention; 
Figure 2 is a block diagram of a configuration used to exchange data; 
Figure 3 is a listing of tags that contain envelope and data information; 
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Figure 4 is a listing of tags that contain delivery information; 
Figure 5 is a listing of tags that contain manifest information; and 
Figure 6 illustrates a part order schema. 

DETAILED DESCRIPTION OF THE INVENTION 

Although not required, the invention will be described in the general context of computer- 
executable instructions, such as program modules, that are executed by a personal computer or a 
server. Generally, program modules include routines, programs, objects, components, data 
structures, etc., that perform particular tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the invention may be practiced with other 
computer system configurations, including hand-held devices, multiprocessor systems, 
microprocessor-based or programmable consumer electronics, network PCS, minicomputers, 
mainframe computers, and the like. The invention may also be practiced in distributed 
computing environments where tasks are performed by remote processing devices that are linked 
through a communications network. In a distributed computing environment, program modules 
may be located in both local and remote memory storage devices. 

Figure 1 is a schematic diagram of a conventional general-purpose digital computing 

environment that can be used to implement various aspects of the invention. Computer 100 

includes a processing unit 1 10, a system memory 120 and a system bus 130 that couples various 

system components including the system memory to the processing unit 1 10. System bus 130 

may be any of several types of bus structures including a memory bus or memory controller, a 
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peripheral bus, and a local bus using any of a variety of bus architectures. System memory 120 
includes a read only memory (ROM) 140 and a random access memory (RAM) 150. 

A basic input/output system (BIOS) 160 containing the basic routines that help to transfer 
information between elements within the computer 100, such as during start-up, is stored in ROM 
5 140. Computer 100 also includes a hard disk drive 170 for reading from and writing to a hard 
disk (not shown), a magnetic disk drive 1 80 for reading from or writing to a removable magnetic 
disk 190, and an optical disk drive 191 for reading from or writing to a removable optical disk 
192, such as a CD ROM or other optical media. Hard disk drive 170, magnetic disk drive 180, 
and optical disk drive 191 are respectively connected to the system bus 130 by a hard disk drive 
10 interface 192, a magnetic disk drive interface 193, and an optical disk drive interface 194. The 
drives and their associated computer-readable media provide nonvolatile storage of computer 
readable instructions, data structures, program modules and other data for personal computer 100. 
It will be appreciated by those skilled in the art that other types of computer readable media 
which can store data that is accessible by a computer, such as magnetic cassettes, flash memory 
15 cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only 
memories (ROMs), and the like, may also be used in the exemplary operating environment. 

A number of program modules cak be stored on the hard disk, magnetic disk 190, optical 



disk 192, ROM 140 or RAM 150, including an operating system 195, one or more application 

programs 196, other program modules 197, anaj>rogram data 198. A user can enter commands 

20 and information into computer 1 00 through input ofevices, such as a keyboard 1 0 1 and a pointing 

device 102. Other input devices (not shown) may include a microphone, joystick, game pad, 
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satellite dish, scanner, or thk like. These and other input devices are often connected to the 
processing unit 1 10 through a serial port interface 106 that is coupled to the system bus, but may 
be connected by other interfaces, such as a parallel port, a game port, a universal serial bus (USB) 



or through a PCI board. A monitor \07 or other type of display device is also connected to 
5 system bus 1 30 via an interface, such as aVideo adapter 108. In addition to the monitor, personal 
computers typically include other peripheral output devices (not shown), such as speakers and 
printers. 

q Computer 100 can operate in a networked^nvironment using logical connections to one 

or more remote computers, such as a remote computer 109. Remote computer 109 can be a 
10 server, a router, a network PC, a peer device or other common network node, and typically 
includes many or all of the elements described above relative to computer 100, although only a 
memory storage device 1 1 1 has been illustrated in Figure 1 . The logical connections depicted in 
Figure 1 include a local area network (LAN) 1 12 and a wide area network (WAN) 113. Such 
networking environments are commonplace in offices, enterprise-wide computer networks, 
1 5 intranets and the Internet. 

When used in a LAN networking environment, computer 100 is connected to local 
network 1 12 through a network interface or adapter 1 14. When used in a WAN networking 
environment, personal computer 100 typically includes a modem 115 or other means for 
establishing a communications over wide area network 113, such as the Internet. Modem 1 15, 
20 which may be internal or external, is connected to system bus 1 30 via serial port interface 106. 
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In a networked environment, program modules depicted relative to personal computer 100, or 
portions thereof, may be stored in the remote memory storage device. 

It will be appreciated that the network connections shown are exemplary and other ways 
of establishing a communications link between the computers can be used. The existence of any 
of various well-known protocols, such as TCP/IP, Ethernet, FTP, HTTP and the like, is 
presumed, and the system can be operated in a client-server configuration to permit a user to 
retrieve web pages from a web-based server. Any of various conventional web browsers can be 
used to display and manipulate data on web pages. 

Figure 2 is a functional block diagram of elements that may be used in accordance with 

the present invention to exchange data from a source location to a destination location. 

Application 200 may be a computer program located at the source location. An adapter 202 may 

be an application that creates a software envelope 204 that contains data 206. In this patent the 

term "envelope" refers to information that defines a delivery convention such as one or more of 

routing information, return routing information and state management information, much in the 

same way that a postal system envelope defines a convention where routing and delivery can be 

accomplished independent of the final purpose, processing, disposition, and information of the 

contents of the envelope. Of course, this list is not intended to limit or define the exact 

information of any particular envelope, but simply illustrate the types of information that may be 

included in an envelope. In an alternative embodiment, application 200 may contain computer 

code for performing the function of adapter 202. An example of software envelope 204 is 

described in detail below. A server 208 may handle and route software envelope 204 to the 
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destination location. A single server is shown for illustration purposes only and with the 
understanding that two or more servers may be connected between the source and destination 
points as is conventionally done in computer networks such as the Internet. Furthermore, 
software envelope 204 may be transmitted between application 200 and application 212 via any 

5 number of data transmission mechanisms including electronic mail and HTTP. An adapter 2 1 0 
extracts data 206 from software envelope 204 for further processing by an application 212. 

The present invention may use a markup language, such as the extensible markup 
language (XML) or the standard generalized markup language (SGML) to create and transmit 
envelopes and data. Figure 3 shows XML tags that may be used to form an envelope that 

1 0 contains data. The <envelope type> tags 302 may be used to identify the type of envelope and an 
associated namespace 303 so that the envelope can be processed by the server. Namespace 303 
may identify element declarations. When using the BizTalk Framework and BizTalk servers, 
opening tag 302 may be replaced with <biztalk_l xmlns="urn:biztalk-org:biztalk:biztalk_r'>. 
The information contained within the <header> tags 304 may contain delivery and message 

15 content information. Delivery information may be contained within <delivery> tags 306 and 
message content information may be contained within <manifest> tags 308. Furthermore, data 
206 (shown in figure 2) may be contained within <body> tags 310. 

Figure 4 shows the type of information that may be included within <delivery> tags 306. 
The information between <message> tags 402 may contain unique information specific to the 

20 particular data being exchanged. For example, an envelope identification code 403 may be 
contained within <messageID> tags 404. Envelope identification code 403 may be used for 
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logging, tracking, error handling, or other message processing/reprocessing requirements. 
Application 200 or adapter 202 (shown in figure 2) may generate a unique envelope identification 
code for each envelope. The <sent> tags 406 may contain a time stamp 405 indicating when the 
envelope was transmitted from an application. Time stamp 405 may use the ISO 8601 format. 
5 Text 407 describing the contents of the envelope may be contained within <subject> tags 

408. For example, figure 4 includes text 407 indicating that the envelope contains data for 
ordering parts. 

The destination location for the envelope may be contained within the <to> tags 410. 
The information contained within <from> 412 pertains to the source location and may be similar 

10 to the information contained within <to> tags 410 and described below. A Universal Resource 
Identifier (URI) describing the logical address of a destination location may be included within 
<address> tags 414. The logical address of a source or destination location may be independent 
of the transport mechanism used to transport the envelope. However, if Application 200 or 
adapter 202 (shown in figure 2) is already configured with a transport specific URL 413 for the 

1 5 destination system, it can be specified in place of the URI. In one embodiment of the invention, 
server 208 (shown in figure 2) may be used to resolve a destination location URI into the 
appropriate transport- specific address when provided with a logical identifier of the destination 
location. 

State information may be contained within <state> tags 416. State information may be 

20 used to correlate individual messages with specific exchanges and processes and may include 

interchange, handle, and state identifiers. For example, state information may instruct the 
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recipient of an envelope to send replies to an address that is different from the source location. 

The present invention allows the recipient of an envelope containing data to conveniently 
reply to the sender. In particular, the information making up the envelope can be used to 
automatically create a new reply envelope. In one embodiment of the invention, application 2 1 2 
or adapter 210 (shown in figure 2) creates a new envelope with the source and destination address 
information reversed. Furthermore, state information may be used to indicate that a response 
should be sent to an address other than the source address. For example, state information 
attached to a purchase order may indicate that an order acknowledgement reply should be sent to 
a second address while a shipping notice reply should be sent to a third address. 

Figure 5 shows the type of information that may be contained within the <manifest> tags 

308. Such information may indicate the type of information contained in the software envelope. 

The identification of each data file 206, shown in figure 2 and described in detail below, is found 

between a pair of <document> tags 502. Figure 5 shows a single document 501 for illustration 

purposes only. When two or more documents are sent in the same envelope, they may be listed 

between the <manifest> tags 308 in the same order that they appear between <body> tags 3 10 to 

facilitate the processing of the information. The name of the data file corresponding to element 

206, shown in figure 2, may be contained within <name> tags 504. A textual description of the 

data file may be contained within <description> tags 508. Comments that may be useful or 

requested by the source location, such as keywords that facilitate searching, may be include 

between <description> tags 508. 

The present invention also allows for the attachment of one or more files to the software 
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envelope by describing the attachments between a pair of <attachment> tags 510 for each 
attached file. The name of an attached file may be included between <filename> tags 512 and a 
textual description of the attached file may be contained within <description> tags 5 14. The type 
of file may be included between <type> tags 516. There are many situations in which a user may 
5 want to attach a file to the software envelope. For example, a user may want to attach prices 
found in an advertisement distributed by a supplier to an envelope containing a part order request. 
The user can scan the advertisement and create an image in JPG format. Figure 5 shows what 
O the manifest format may look like when a user attaches a JPG image of an advertisement to a part 

order request. When more than one file is attached to a software envelope, each attachment may 

: c 

Hi 10 be identified by a unique index number placed between <index> tags (not shown). 

y i 

J Data file 206 (shown in figure 2) may be contained between <body> tags. Data file 206 is 

□ preferably marked up with a markup language that matches the markup used for software 

fn 

fU envelope 204. The format of the marked up file will be in accordance with a schema agreed upon 

yp " ^ ■ ■ 

P by the source and destination locations. Figure 6 shows an example of a marked up data file. 

r~ % ~ 

— — ■ 

15 Opening schema tag 602 identifies the schema as !l part_order_3." A namespace reference 603 
may be included to distinguish namespace 603 associated with the schema from namespace 303 
associated with opening element type tag 302. A variety of information and corresponding tags 
make up the document 604, which corresponds to data 206 shown in figure 2. As an example, 
figure 6 shows a document 604 used for ordering parts. The identification of the schema allows 

20 application 2 1 2 or adapter 2 1 0 to use an appropriate plugin to parse and extract the data from the 

data file. A plugin may implement the design pattern by which object constructors are linked 
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with Document Object Model (DOM) nodes that are contained within the software envelope. For 
example, a plugin constructed in accordance with schema part_order_3 would know that the part 
number corresponding to the part being ordered would be found between the <partNo> tags. 
Furthermore, a schema may indicate that certain information is optional. For example, the 
description information found between the <description> tags shown in figure 6 may be optional. 
The corresponding plugin may extract optional information if it is present. 

The appropriate plugin may depend upon the operating system utilized by the destination 
location. For example, a first plugin may extract the information contained in the data file shown 
in figure 6 and rehydrate the information into an object recognized by the first operating system. 
Furthermore, a second plugin may be used to extract and rehydrate the same information into an 
object recognized by a second operating system. In one embodiment of the invention, a plugin or 
parser may be attached to the software envelope. 

While the present invention has been described in connection with the illustrated 
embodiments, it will be appreciated and understood that modifications may be made without 
departing from the true spirit and scope of the invention. 




12 



